Minutes, IBIS Quality Committee

23 Oct 2007

11-12 AM EST (8-9 AM PST)

ROLL CALL
  Adam Tambone
  Barry Katz, SiSoft
  Benny Lazer
  Benjamin P Silva
  Bob Cox, Micron
* Bob Ross, Teraspeed Consulting Group
  Brian Arsenault
* David Banas, Xilinx
* Eckhard Lenski, Nokia Siemens Networks
  Eric Brock
  Gregory R Edlund
  Hazem Hegazy
  John Figueroa
  John Angulo, Mentor Graphics
  Katja Koller, Nokia Siemens Networks
  Kevin Fisher
* Kim Helliwell, LSI Logic
  Lance Wang, IOMethodology
  Lynne Green
* Mike LaBonte, Cisco Systems
  Mike Mayer, SiSoft
  Moshiul Haque, Micron Technology
  Peter LaFlamme
  Radovan Vuletic, Qimonda
  Robert Haller, Enterasys
  Roy Leventhal, Leventhal Design & Communications
  Sherif Hammad, Mentor Graphics
  Todd Westerhoff, SiSoft
  Tom Dagostino, Teraspeed Consulting Group
* Kazuyoshi Shoji, Hitachi
  Sadahiro Nonoyama

Everyone in attendance marked by *

NOTE: "AR" = Action Required.

-----------------------MINUTES ---------------------------
Mike LaBonte conducted the meeting.

Call for patent disclosure:

- No one declared a patent.

AR Review:

- Mike ask David Banas to write a response email to JEITA.
  - Done

New items:

Kazuyoshi Shohji, representing JEITA, has sent an updated version of JEITA's
comments on the IBIS Quality Specification.
- He described JEITA's itemized comments on the specification:

- Item #1: 1.1.3. IQ2  Suitable for Waveform Simulation
  - Shohji: There is no description of the bullet items listed in this section.
  - Mike: This content is temporary and will be replaced when all items
    have been reviewed.
- Item #2: 1.1.5. IQ4  Suitable for Power Analysis
  - Shohji: It is too early for BIRD95
  - Mike: BIRD95 may be in a released spec not long after IQ 1.1 is released.
  - Bob: It will be another year or 2 before BIRD95 is in approved
  - Mike recalled a more optimistic estimate of next spring
  - The IQ group felt that retaining IQ4 as a placeholder is reasonable.
  - Shohji: It would be best to add a comment about this to IQ.
- Item #3: 1.2.3. Designator "X" - Exceptions
           2.1. {LEVEL 1} IBIS file passes IBISCHK
  - Shohji: X should be used only when the IBIS file contains important messages
  - Kim: X will always have an explanation associated with it.
  - Shoji: Important to have X to indicate that user should open the file
    - Should not need X for parser bugs
  - Example: Vmeas not between Vinl and Vinh
  - Example: Package may legitimately have large RLC value
  - IQ 2.1 calls for X designator for IBISCHK warnings
  - Should non-monotonic IV have an X?
    - Yes, if the combined curves are non-monotonic.
    - Some tools handle this better than others.
  - Kim: all warnings must be documented, but not necessarily have an X.
  - Mike: don't use X for parser bugs
    - Kim and Bob disagree.
- Item #4: 3.2.1. {LEVEL 2}  [Pin] section complete
  - Shohji: Would prefer that listing special pins is only recommended.
- Item #5: 3.2.1. {LEVEL 2}  [Pin] section complete
  - Delete: "For IBIS buffer [Model] libraries, it is recommended that one pin be used for every model and that the pin name be the same as the model name."
- Item #6: 3.2.5. {LEVEL 3}  [Pin] RLC parasitics are present and reasonable
  - Shoji: other JEITA members feel the number values should be higher
    - Stack packages may exceed 300ps delay.
  - We decided to leave as is for now.
  - Kim: This is useful as a sanity check.
- Item #7: 4.2. {LEVEL 2} Default [Model Selector] entries are consistent
  - Shohji: This is OK as long as this is a suggestion.
  - Bob: may want to list strengths in order, even if a middle one is most freq.
- Item #8: 5.1.4. {LEVEL 2}  [Model] C_comp is correct
  - Shohji: This is just a comment, there is no requirement stated
  - Mike: agreed, this needs work.
- Item #9: 5.1.7. {LEVEL 2}  [Temperature Range] is reasonable
  - Shohji: Data sheets give temperature limits for package, not for die
- Item #10: 5.2.5 through 5.2.25
  - Shoji: Some parts do not need [Model Spec] or [Receiver Thresholds]
  - David: Tools like SiSoft use this information
  - These checks apply only when the data is present.
    - They do not require [Model Spec] and [Receiver Thresholds]
  - DDR2 devices require [Receiver Thresholds], for example
  - The checks should make clear that they do not require the data.


Next meeting:

30 Oct 2007
11-12 AM EST (8-9 AM PST)
Phone: 1.877.384.0543 or 1.800.743.7560
Passcode: 90437837

Meeting ended at 12:12 PM Eastern Time.